This disclosure relates generally to transactional execution, and more specifically to salvaging a hardware transaction with a salvage indicator instruction.
The number of central processing unit (CPU) cores on a chip and the number of CPU cores connected to a shared memory continues to grow significantly to support growing workload capacity demand. The increasing number of CPUs cooperating to process the same workloads puts a significant burden on software scalability; for example, shared queues or data-structures protected by traditional semaphores become hot spots and lead to sub-linear n-way scaling curves. Traditionally this has been countered by implementing finer-grained locking in software, and with lower latency/higher bandwidth interconnects in hardware. Implementing fine-grained locking to improve software scalability can be very complicated and error-prone, and at today's CPU frequencies, the latencies of hardware interconnects are limited by the physical dimension of the chips and systems, and by the speed of light.
Implementations of hardware Transactional Memory (HTM, or in this discussion, simply TM) have been introduced, wherein a group of instructions—called a transaction—operate in an atomic manner on a data structure in memory, as viewed by other central processing units (CPUs) and the I/O subsystem (atomic operation is also known as “block concurrent” or “serialized” in other literature). The transaction executes optimistically without obtaining a lock, but may need to abort and retry the transaction execution if an operation, of the executing transaction, on a memory location conflicts with another operation on the same memory location. Previously, software transactional memory implementations have been proposed to support software Transactional Memory (TM). However, hardware TM can provide improved performance aspects and ease of use over software TM.
U.S. Pat. No. 7,587,615 titled “Utilizing Hardware Transactional Approach to Execute Code After Initially Utilizing Software Locking By Employing Pseudo-Transactions” filed Sep. 12, 2004, incorporated by reference herein in its entirety, teaches utilizing a hardware transactional approach to execute a code section by employing pseudo-transactions, after initially utilizing software locking. A method is disclosed that utilizes a software approach to locking memory to execute a code section relating to memory. The software approach employs a pseudo-transaction to determine whether a hardware approach to transactional memory to execute the threshold would have been successful. Where the hardware approach to transactional memory to execute the code section satisfies a threshold based on success of at least the pseudo-transaction, the method subsequently utilizes the hardware approach to execute the code section. The hardware approach may include starting a transaction inclusive of the code section, conditionally executing the transaction, and, upon successfully completing the transaction, committing execution of the transaction to the memory to which the code section relates.
U.S. Patent Application Publication No. 2010/0013899 titled “Using Hardware Transaction Primitives for Implementing Non-Transactional Escape Actions Inside Transactions” filed Jul. 6, 2011, incorporated by reference herein in its entirety, teaches mechanisms that are provided for performing escape actions within transactions. These mechanisms execute a transaction comprising a transactional section and an escape action. The transactional section is comprised of one or more instructions that are to be executed in an atomic manner as part of the transaction. The escape action is comprised of one or more instructions to be executed in a non-transactional manner. These mechanisms further populate at least one actions list data structure, associated with a thread of the data processing system that is executing the transaction, with one or more actions associated with the escape action. Moreover, these mechanisms execute one or more actions in the actions list data structure based upon whether the transaction commits successfully or is aborted.
U.S. Patent Application Publication No. 2010/0169623 titled “Method and System for Reducing Abort Rates in Speculative Lock Elision using Contention Management Mechanisms” filed Dec. 29, 2008, incorporated by reference herein in its entirety, teaches that hardware-based transactional memory mechanisms, such as Speculative Lock Elision (SLE), may allow multiple threads to concurrently execute critical sections protected by the same lock as speculative transactions. Such transactions may abort due to contention or due to misidentification of code as a critical section. In various embodiments, speculative execution mechanisms may be augmented with software and/or hardware contention management mechanisms to reduce abort rates. Speculative execution hardware may send a hardware interrupt signal to notify software components of a speculative execution event (e.g., abort). Software components may respond by implementing concurrency-throttling mechanisms and/or by determining a mode of execution (e.g., speculative, non-speculative) for a given section and communicating that determination to the hardware speculative execution mechanisms, e.g., by writing it into a lock predictor cache. Subsequently, hardware speculative execution mechanisms may determine a preferred mode of execution for the section by reading the corresponding entry from the lock predictor cache.
U.S. Patent Application Publication No. 2012/0084477 titled “Transactional Memory Preemption Mechanism” filed Sep. 30, 2010, incorporated by reference herein in its entirety, teaches mechanisms for executing a transaction in a data processing system. A transaction checkpoint data structure is generated in internal registers of a processor. The transaction checkpoint data structure stores transaction checkpoint data representing a state of program registers at a time prior to execution of a corresponding transaction. The transaction, which comprises a first portion of code that is to be executed by the processor, is executed. An interrupt of the transaction is received while executing the transaction and, as a result, the transaction checkpoint data is stored to a data structure in a memory of the data processing system. A second portion of code is then executed. A state of the program registers is restored using the data structure in the memory of the data processing system in response to an event occurring causing a switch of execution of the processor back to execution of the transaction.